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Abstract. Answer Set Programming (ASP) is a declarative logic programming formalism, which is 
employed nowadays in both academic and industrial real-world applications. Although some tools for 
supporting the development of ASP programs have been proposed in the last few years, the crucial task 
of testing ASP programs received less attention, and is an Achilles' heel of the available programming 
environments. 

In this paper we present a language for specifying and running unit tests on ASP programs. The test- 
ing language has been implemented in ASPIDE, a comprehensive IDE for ASP, which supports the 
entire life-cycle of ASP development with a collection of user-friendly graphical tools for program 
composition, testing, debugging, profiling, solver execution configuration, and output-handling. 

1 Introduction 

Answer Set Programming (ASP) [1] is a declarative logic programming formalism proposed in the area 
of non-monotonic reasoning. The idea of ASP is to represent a given computational problem by a logic 
program whose answer sets correspond to solutions, and then use a solver to find those solutions J5) . 

The language of ASP 1 1 1 supports a number of modeling constructs including disjunction in rule heads, 
nonmonotonic negation |1|, (weak and strong) constraints [3|, aggregate functions |4), and more. These 
features make ASP very expressive [5 1, and suitable for developing advanced real-world applications. ASP 
is employed in several fields, from Artificial Intelligence [6 7 8 9 101111 to Information Integration [12|, 
and Knowledge Management H 1 31 141 . Interestingly, these applications of ASP recently have stimulated 
some interest also in industry [ 14 1. 

On the one hand, the effective application of ASP in real-world scenarios was made possible by the 
availability of efficient ASP systems [6 18,19]. On the other hand, the adoption of ASP can be further 
boosted by offering effective programming tools capable of supporting the programmers in managing large 
and complex projects ll20l . 

In the last few years, a number of tools for developing ASP programs have been proposed, including 
editors and debuggers 112 1 122123 124I25I26I27I28I29I30I3 1 1 . Among them, ASPIDE ED -which stands for 
Answer Set Programming Integrated Development Environment- is one of the most complete development 
tools^Jand it integrates a cutting-edge editing tool (featuring dynamic syntax highlighting, on-line syntax 
correction, autocompletion, code-templates, quick-fixes, refactoring, etc.) with a collection of user-friendly 
graphical tools for program composition, debugging, profiling, DBMS access, solver execution configura- 
tion and output-handling. 

Although so many tools for developing ASP programs have been proposed up to now, the crucial 
task of testing ASP programs received less attention [32 46], and is an Achilles' heel of the available 
programming environments. Indeed, the majority of available graphic programming environments for ASP 
does not provide the user with a testing tool (see ||3T| ), and also the one present in the first versions of 
ASPIDE is far from being effective. 

In this paper we present a pragmatic solution for testing ASP programs. In particular, we present a new 
language for specifying and running unit tests on ASP programs. The testing language presented in this 
paper is inspired by the JUnit [33 1 framework: the developer can specify the rules composing one or sev- 
eral units, specify one or more inputs and assert a number of conditions on both expected outputs and the 

1 For an exaustive feature-wise comparison with existing environments for developing logic programs we refer the 
reader to 1311 . 



expected behavior of sub-programs. The obtained test case specification can be run by exploiting an ASP 
solver, and the assertions are automatically verified by analyzing the output of the chosen ASP solver. Note 
that test case specification is applicable independently of the used ASP solver. The testing language was 
implemented in ASPIDE, which also provides the user with some graphic tools that make the development 
of test cases simpler. The testing tool described in this work extends significantly the one formerly available 
in ASPIDE, by both extending the language by more expressive (non-ground) assertions and the support 
of weak-constraints, and enriching its collection of user-friendly graphical tools (including program com- 
position, debugging, profiling, database management, solver execution configuration, and output-handling) 
with a graphical test suite management interface. 

As far as related work is concerned, the task of testing ASP programs was approached for the first 
time, to the best of our knowledge, in [32 46] where the notion of structural testing for ground normal ASP 
programs is defined and methods for automatically generating tests is introduced. The results presented 
in 1321461 are, somehow, orthogonal to the contribution of this paper. Indeed, no language/implementation 
is proposed in [32 46] for specifying/automatically -running the produced test cases; whereas, the language 
presented in this paper can be used for encoding the output of a test case generator based on the methods 
proposed in (32). Finally, it is worth noting that, testing approaches developed for other logic languages, 
like prolog I34I35I36I . cannot be straightforwardly ported to ASP because of the differences between the 
languages. 

The rest of this paper is organized as follows: in Section [2] we overview ASPIDE; in section [3] we 
introduce a language for specifying unit tests for ASP programs; in Section |4] we describe the user inter- 
face components of ASPIDE conceived for creating and running tests; finally, in Section [5] we draw the 
conclusion. 

2 ASPIDE: Integrated Development Environment for ASP 

ASPIDE is an Integrated Development Environment (IDE) for ASP, which features a rich editing tool 
with a collection of user-friendly graphical tools for ASP program development. In this section we first 
summarize the main features of the system and then we overview the main components of the ASPIDE 
user interface. For a more detailed description of ASPIDE, as well as for a complete comparison with 
competing tools, we refer the reader to ETl and to the online manual published in the system web site 
|http : / /www .mat . unical . it/ ricca/ aspide| 

System Features. ASPIDE is inspired by Eclipse, one of the most diffused programming environments. 
The main features of ASPIDE are the following: 

- Workspace management. The system allows one to organize ASP programs in projects, which are 
collected in a special directory (called workspace). 

- Advanced text editor. The editing of ASP files is simplified by an advanced text editor. Currently, the 
system is able to load and store ASP programs in the syntax of the ASP system DLV [15|, and sup- 
ports the ASPCore language profile employed in the ASP System Competition 2011 [37 1. ASPIDE 
can also manage TYP files specifying a mapping between program predicates and database tables in 
the Diy DB syntax [38 1. Besides the core functionality that basic text editors offer (like code line num- 
bering, find/replace, undo/redo, copy/paste, etc.), ASPIDE offers other advanced functionalities, like: 
Automatic completion, Dynamic code templates, Quick fix, and Refactoring. Indeed, the system is able 
to complete (on request) predicate names, as well as variable names. Predicate names are both learned 
while writing, and extracted from the files belonging to the same project; variables are suggested by 
taking into account the rule we are currently writing. When several possible alternatives for completion 
are available the system shows a pop-up dialog. Moreover, the writing of repeated programming pat- 
terns (like transitive closure or disjunctive rules for guessing the search space) is assisted by advanced 
auto-completion with code templates, which can generate several rules at once according to a known 
pattern. Note that code templates can also be user defined by writing DLT ll39l files. The refactoring 
tool allows one to modify in a guided way, among others, predicate names and variables (e.g., variable 
renaming in a rule is done by considering bindings of variables, so that variables/predicates/strings 



occurring in other expressions remain unchanged). Reported errors or warnings can be automatically 
fixed by selecting (on request) one of the system's suggested quick fixes, which automatically change 
the affected part of code. 

- Outline navigation. ASPIDE creates an outline view which graphically represents program elements. 
Each item in the outline can be used to quickly access the corresponding line of code (a very useful 
feature when dealing with long files), and also provides a graphical support for building rules in the 
visual editor (see below). 

- Dynamic code checking and error highlighting. Syntax errors and relevant conditions (like safety) 
are checked while typing programs: portions of code containing errors or warnings are immediately 
highlighted. Note that the checker considers the entire project, and warns the user by indicating e.g., 
that atoms with the same predicate name have different arity in several files. This condition is usually 
revealed only when programs divided in multiple files are run together. 

- Dependency graph. The system is able to display several variants of the dependency graph associated 
to a program (e.g., depending on whether both positive and negative dependencies are considered). 

- Debugger and Profiler. Semantic error detection as well as code optimization can be done by exploiting 
graphic tools. In particular, we developed a graphical user interface for embedding in ASPIDE the 
debugging tool spock [23 1 (we have also adapted spock for dealing with the syntax of the DLV system). 
Regarding the profiler, we have fully embedded the graphical interface presented in |40|. 

- Unit Testing. The user can define unit tests and verify the behavior of program units. The language for 
specifying unit tests, as well as the graphical tools of ASPIDE assisting the development of tests, are 
described in detail in the following sections. 

- Configuration of the execution. This feature allows one to configure and manage input programs and 
execution options (called run configurations). 

- Presentation of results. The output of the program (either answer sets, or query results) are visualized 
in a tabular representation or in a text-based console. The result of the execution can be also saved in 
text files for subsequent analysis. 

- Visual Editor. The users can draw logic programs by exploiting a full graphical environment that 
offers a QBE-like tool for building logic rules ATI . The user can switch, every time he needs, from the 
text editor to the visual one (and vice-versa) thanks to a reverse-engineering mechanism from text to 
graphical format. 

- Interaction with databases. Interaction with external databases is useful in several applications (e.g., H3). 
ASPIDE provides a fully graphical import/export tool that automatically generates mappings by fol- 
lowing the Diy DB TYP file specifications |38|. Text editing of TYP mappings is also assisted by 
syntax coloring and auto-completion. Database oriented applications can be run by setting DLY DB as 
solver in a run configuration. 

Interface Overview The user interface of ASPIDE is depicted in Figure [T] The most common operations 
can be quickly executed through a toolbar present in the upper part of the GUI (zone 1). From left to right 
there are buttons allowing to: save files, undo/redo, copy & paste, find & replace, switch between visual to 
text editor, run the solver/profiler/debugger. The main editing area (zone 4) is organized in a multi-tabbed 
panel possibly collecting several open files. On the left there is the explorer panel (zone 2) which allows 
one to browse the workspace; and the error console (zone 3). The explorer panel lists projects and files 
included in the workspace, while the error console organizes errors and warnings according to the project 
and files where they are localized. On the right, there are the outline panel (zone 5) and the sources panel 
(zone 6). The first shows an outline of the currently edited file, while the latter reports a list of the database 
sources connected with the current project. Note that, the layout of the system can be customized by the 
user, indeed panels can be moved and rearranged. 

ASPIDE is written in Java and runs on the most diffused operating systems (Microsoft Windows, Linux, 
and Mac OS) and can connect to any database supporting Java DataBase Connectivity (JDBC). 

3 A language for testing ASP programs 

Software testing 11421 is an activity aimed at evaluating the behavior of a program by verifying whether it 
produces the required output for a particular input. The goal of testing is not to provide means for estab- 




Fig. 1. The ASPIDE graphical user interface. 



lishing whether the program is totally correct; conversely testing is a pragmatic and cheap way of finding 
errors by executing some test. A test case is the specification of some input I and corresponding expected 
outputs O. A test case fails when the outputs produced by running the program does not correspond to O, 
it passes otherwise. 



One of the most diffused white-bo^ testing techniques is unit testing. The idea of unit testing is to 
assess an entire software by testing its subparts called units (and corresponding to small testable parts of 
a program). In a software implemented by using imperative object-oriented languages, unit testing corre- 
sponds to assessing separately portions of the code like class methods. The same idea can be applied to 
ASP, once the notion of unit is given. We intend as unit of an ASP programs P any subset of the rules of P 
corresponding to a splitting set B31 (actually the system exploits a generalization of the splitting theorem 
by Lifschitz and Turner |43| to the non-ground case [44 1). In this way, the behavior of units can be verified 
(by avoiding unwanted behavioral changes due to cycles) both when they run isolated from the original 
program as well as when they are left immersed in (part of) the original program. 

In the following, we present a pragmatic solution for testing ASP programs, which is a new language, 
inspired by the JUnit ll33l framework, for specifying and running unit tests. The developer, given an ASP 
program, can select the rules composing a unit, specify one or more inputs, and assert a number of condi- 
tions on the expected output. The obtained test case specification can be run, and the assertions automati- 
cally verified by calling an ASP solver and checking its output. In particular, we allow three test execution 
modes: 

- Execution of selected rules. The selected rules will be executed separated from the original program 
on the specified inputs. 

- Execution of split program. The program corresponding to the splitting set containing the atoms of the 
selected rules is run and tested. In this way, the "interface" between two splitting sets can be tested 
(e.g., one can assert some expected properties on the candidates produced by the guessing part of a 
program by excluding the effect of some constraints in the checking part). 

- Execution in the whole program. The original program is run and specific assertions regarding predi- 
cates contained in the unit are checked. This corresponds to filtering test results on the atoms contained 
in the selected rules. 

Testing Language. A test file can be written according to the following grammar]^] 
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invocation ( " invocationName " [ , "solverPath" , "options" ]?); 

[ [ input ( "program" ) ; ] I [ inputFile ( "file" ) ; ] ]* 

[ 

testCaseName ( [ selected_rules I split_program | program ]?) 
{ 

[newOptions ("options") ; ] ? 

[ [ input ( "program" ) ; ] | [ inputFile ( "file" ) ; ] ]* 

[ [ excludelnput ( "program" ) ; ] 

| [ excludelnputFile ( "file" ) ; ] ]* 

[ 

[ filter | pfilter | nfilter ] 

[ [ ( predicateName [ , predicateName ] * ) ] 

| [SELECTED_RULES] ] ; 
]? 

[ selectRule (ruleName) ; ]* 

[ [ assertName ( [ intnumber, ]? [ [ "atoms" ] | [ "constraint" ] ) ; ] 

I [ assertBestModelCost (intcost [, intlevel ] ? ) ; ] ] * 

} 

i* 

[ [ assertName ( [ intnumber, ] ? [ [ "atoms" ] I [ "constraint" ] ) ; ] 

[ assertBestModelCost (intcost [, intlevel ]? ) ; ] ]* 



A test file might contain a single test or a test suite (a set of tests) including several test cases. Each test 
case includes one or more assertions on the execution results. 

The invocation statement (line 1) sets the global invocation settings, that apply to all tests specified 
in the same file (name, solver, and execution options). In the implementation, the invocation name might 
correspond to an ASPIDE run configuration, and the solver path and options are not mandatory. 

2 A test conceived for verifying some functionality of an application without knowing the code internals is said to 
be a black-box test. A test conceived for verifying the behavior of a specific part of a program is called white-box 
test. White box testing is an activity usually carried out by developers and is a key component of agile software 
development [42|. 

3 Non- terminals are in bold face; token specifications are omitted for simplicity. 



The user can specify one or more global inputs by writing some input and inputFile statements (line 2). 
The first kind of statement allows one for writing the input of the test in the form of ASP rules or simply 
facts; the second statement indicates a file that contains some input in ASP format. 

A test case declaration (line 4) is composed by a name and an optional parameter that allows one to 
choose if the execution will be done on the entire program, on a subset of rules, or on the program cor- 
responding to the splitting set containing the selected rules. The user can specify particular solver options 
(line 6), as well as certain inputs (line 7) which are valid in a given test case. Moreover, global inputs of the 
test suite can be excluded by exploiting excludelnput and excludelnputFile statements (lines 8 and 9). The 
optional statements filter, pfilter and nfilter (lines 11, 12, and 13) are used to filter out output predicates 
from the test results (i.e., specified predicate names are filtered out from the results when the assertion is 
executed)]^] The statement selectRule (line 15) allows one for selecting rules among the ones composing 
the global input program. A rule r to be selected must be identified by a name, which is expected to be 
specified in the input program in a comment appearing in the row immediately preceding r (see Figure[T]l. 
ASPIDE adds automatically the comments specifying rule names. If a set of selected rules does not belong 
to the same splitting set, the system has to print a warning indicating the problem. 

The expected output of a test case is expressed in terms of assertion statements (lines 16/21). The 
possible assertions are: 

- assertTruef "atomList" )/assertCautiouslyTrue(" atomList" '). Asserts that all atoms of the atom list must 
be true in any answer sets; 

- assertBravelyTruef "atomList" ). Asserts that all atoms of the atom list must be true in at least one 
answer set; 

- assertTruelnfnumber, "atomList"). Asserts that all atoms of the atom list must be true in exactly num- 
ber answer sets; 

- assertTruelnAtLeastfnumber, "atomList"). Asserts that all atoms of the atom list must be true in at 
least number answer sets; 

- assertTruelnAtMostfnumber, "atomList"). Asserts that all atoms of the atom list must be true in at most 
number answer sets; 

- assertConstraintf " .--constraint." ). Asserts that all answer sets must satisfy the specified constraint; 

- assertConstraintIn(number, ".--constraint."). Asserts that exactly number answer sets must satisfy the 
specified constraint; 

- assertConstraintlnAtLeastfnumber, ".--constraint."). Asserts that at least number answer sets must sat- 
isfy the specified constraint; 

- assertConstraintlnAtMostfnumber, ".--constraint."). Asserts that at most number answer sets must sat- 
isfy the specified constraint; 

- assertBestModelCost(intcost) and assertBestModelCostfintcost, intlevel). In case of execution of pro- 
grams with weak constraints, they assert that the cost of the best model with level intlevel must be 
intcost; 

together with the corresponding negative assertions: assertFalse, assertCautiouslyFalse, assertBravely- 
False, assertFalseln, assertFalselnAtLeast, assertFalselnAtMost. The atomList specifies a list of atoms 
that can be ground or non-ground; in the case of non-ground atoms the assertion is true if some ground 
instance matches in some/all answer sets. Assertions can be global (line 20-21) or local to a single test (line 
16-17). 

In the following we report an example of test case. 

Test case example. The maximum clique is a classical hard problem in graph theory requiring to find the 
largest clique (i.e., a complete subgraph of maximal size) in an undirected graph. Suppose that the graph 
G is specified by using facts over predicates node (unary) and edge (binary), then the program in Figure [T] 
solves the problem. 

The disjunctive rule (ri) guesses a subset S of the nodes to be in the clique, while the rest of the pro- 
gram checks whether S constitutes a clique, and the weak constraint (rs) maximizes the size of S. Here, 

4 pfilter selects only positive literals and excludes the strongly negated ones, while nfilter has opposite behavior. 
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an auxiliary predicate uedge exploits an ordering for reducing the time spent in checking. Suppose that 
the encoding is stored in a file named clique, dl; and suppose also that the graph instance, composed by 
facts { node(l). node(2). node(3). node(4). node(5). node(6). node(7). edge(l,2). edge(2,3). edge(2,4). 
edge(l,4). edge(l,5). edge(4,5). edge(2,5). edge(4,6). edge(5,7). edge(3,7).}, is stored in the file named 
graphlnstance.dl (the corresponding graph is depicted in Figure [2^). The following is a simple test suite 
specification for the above-reported ASP program: 

invocation ( "MaximalClique " , " /usr/bin/dlv" , ""); 

input File ( " clique . dl " ) ; 

input File ( "graphlnstance . dl " ) ; 

maximalClique ( ) 

{ 

assertBestModelCost (3) ; 

} 

constraintsOnCliques () 

{ 

excludelnput (" : ~ outClique (X2 } . " ) ; 

assert Constraint InAtLeast ( 1 , " : - not inClique ( 1 ) , not inClique ( 4 ) . " ) ; 
assertConstraintln (5, " : - #count{ XI: inClique (XI) } < 3."); 

} 

CheckNodeOrdering (SELECTED_RULES) 
{ 

input File ( "graphlnstance . dl " ) ; 

selectRule ("r2") ; 

selectRule ( "r3" ) ; 

assert False ( "uedge (2,1) . " ) ; 

} 

guessClique ( SPLIT_PROGRAM) 
{ 

selectRule ( "rl" } ; 

assertFalselnAtMost (1, "inClique (X) . " ) ; 
assertBravelyTrue ( " inClique (X) . " ) ; 

} 

Here, we first set the invocation parameters by indicating DLV as solver, then we specify the file to be 
tested clique.dl and the input file graphlnstance.dl, by exploiting a global input statement; then, we add the 
test case maximalClique, in which we assert that the best model is expected to have a cost (i.e., the number 
of weak constraint violations corresponding to the vertexes out of the clique) of 3 (assertBestModelCost(3) 
in Figure [3]). 

In the second test case, named constraintsOnCliques, we require that (i) vertexes 1 and 4 belong to at 
least one clique, and (ii) for exactly five answer sets the size of the corresponding clique is greater than 2. 
(The weak constraint is removed to ensure the computation of all cliques by DLV.) 

In the third test case, named checkNodeOrdering, we select rules r2 and r%, and we require to test 
selected rules in isolation, discarding all the other statements of the input. We are still interested in con- 
sidering ground facts that are included locally (i.e., we include the file graphlnstance.dl). In this case we 
assert that uedge(2,l) is false, since edges should be ordered by rules r-i and r^. 

Test case guessClique is run in SPLIT .PROGRAM modality, which requires to test the subprogram con- 
taining all the rules belonging to the splitting set corresponding to the selection (i.e., {inClique, outClique, 
node}). In this test case the sub-program that we are testing is composed by the disjunctive rule and by 
the facts of predicate node only. Here we require that there is at most one answer set modeling the empty 
clique, and there is at least one answer set modeling a non-empty clique. 
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The test file described above can be created graphically and executed in ASPIDE as described in the 
following section. 
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Fig. 4. Test case execution and assertion management. 



4 Unit Testing in ASPIDE 



In this section we describe the graphic tools implemented in ASPIDE conceived for developing and running 
test cases. Space constraints prevent us from providing a complete description of all the usage scenarios 



and available commands. However, in order to have an idea about the capabilities of the testing interface 
of ASPIDE, we describe step by step how to implement the example illustrated in the previous section. 

Suppose that we have created in ASPIDE a project named MaxClique, which contains the files clique. dl 
and graphlnstance.dl (see Fig.[T| storing the encoding of the maximal clique problem and the graph in- 
stance presented in the previous section, respectively. Moreover we assume that both input files are included 
in a run configuration named MaximalClique, and we assume that the DLV system is the solver of choice in 
MaximalClique. Since the file that we want to test in our example is clique. dl, we select it in the workspace 
explorer, then we click the right button of the mouse and select New Test from the popup menu (Fig. [3^). 
The system shows the test creation dialog (Fig. (3J?), which allows one for both setting the name of the 
test file and selecting a previously-defined run configuration (storing execution options and input files). 
By clicking on the Finish button, the new test file is created (see Fig. |3j;) where a statement regarding 
the selected run configuration is added automatically. We add the first unit test (called maximalClique) by 
exploiting the text editor (see Fig. |3}l), whereas we build the remaining ones (working on some selected 
rules) by exploiting the logic program editor. After opening the clique. dl file, we select rules r-2 and r% 
inside the text editor, we right-click on them and we select Add selected rules in test case from the menu 
item Test of the popup menu (fig. The system opens a dialog window where we indicate the test file 
in which we want to add the new test case (fig. [3]F). We click on the Create test case; the system will ask 
for the name of the new test case and we write guessClique; after that, on the window, we select the option 
execute selected rules and click on the Finish button. The system will add the test case guessClique filled 
with the selectRule statements indicating the selected rules. To add project files as input of the test case, 
we select them from the workspace explorer and click on Use file as input in the menu item Test (fig.[3^). 
We complete the test case specification by adding the assertion, thus the test created up to now is shown in 
figure [3ji. Following an analogous procedure we create the remaining test cases (see Fig. |4^). To execute 
our tests, we right-click on the test file and select Execute Test. The Test Execution Dialog appears and the 
results are shown to the programmer (see Fig. [4}}). Failing tests are indicated by a red icon, while green 
icons indicate passing tests. At this point we add the following additional test: 

checkNodeOutClique ( ) 
{ 

exclude Input ( "edge (2,4) . edge (2,5) . " ) ; 
assert False ( " inClique (2). inClique(5)."); 

} 

This additional test (purposely) fails, this can be easily seen by looking at Figure |2j); and the reason 
for this failure is indicated (see Fig. [4j}) in the test execution dialog. In order to know which literals of 
the solution do not satisfy the assertion, we right-click on the failed test and select Manage Asserts from 
the menu. A dialog showing the outputs of the test appears where, in particular, predicates and literals 
matching correctly the assertions are marked in green, whereas the ones violating the assertion are marked 
in red (gray icons may appear to indicate missing literals which are expected to be in the solution). In 
our example, the assertion is assertFalse("inClique(2). inClique(5)."); however, in our instance, node 5 is 
contained in the maximal clique composed by nodes 1, 4, 5; this is the reason for the failing test. Assertions 
can be modified graphically, and, in this case, we act directly on the result window (fig.|4j;). We remove the 
node 5 from the assertion by selecting it; moreover we right-click on the instance of inClique that specifies 
the node 5 and we select Remove from Assert. The atom node(5) will be removed from the assertion and 
the window will be refreshed showing that the test is correctly executed (see fig. |4^). The same window 
can be used to manage constraint assertions; in particular, by clicking on Manage Constraint Assert of the 
popup menu, a window appears that allows the user to set/edit constraints (see fig.[4ji). 

5 Conclusion 

This paper presents a pragmatic environment for testing ASP programs. In particular, we propose a new 
language, inspired by the JUnit [33 1 framework, for specifying and running unit tests on ASP programs. The 
testing language is general and suits both the DLV lfT5ll and clasp lfl6l ASP dialects. The testing language 
has been implemented in ASPIDE together with some graphic tools for easing both the development of 
tests and the analysis of test execution (via DLV). 



As far as future work is concerned, we plan to extend ASPIDE by improving/introducing additional 
dynamic editing instruments, and graphic tools like VIDEAS |45 1. Moreover, we plan to further improve 
the testing tool by supporting (semi)automatic test case generation based on the structural testing techniques 
proposed in M32I461 . 
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